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REMARKS 

Claims 1-14, 16-30, 34 and 37-45 are now pending in tine case, as claims 31 , 32 

and 36 were previously cancelled. A new claim amendment to claim 1 is made. 

General comments 

While the very complete comments provided by the Examiner in the Advisory 
Action are appreciated, some of them simply leave the applicant poorly equipped to 
respond. With regard to claim 31 , and especially the comment about how the 
amendment of claim 31 to include elements of claim 33 requires "further search and 
consideration", applicant respectfully notes that claim 31 was cancelled in the Response 
After Final and that Claim 33 had been previously cancelled. With regard to claim 34, 
applicant notes that the language questioned by the Examiner ("an input device that 
receives identifiers") was the result of an amendment in the Office Action Response of 9 
November 2009. With regard to claim 37, and as noted elsewhere below, applicant is 
perplexed as to what the Examiner means by the "new grounds of rejection", as there is 
no such grounds set forth by the Examiner. 

Claim amendment 

An amendment to claim 1 corrects an inconsistency in the claim language. At 
lines 17-18, the phrase "mobile device identity data " is used, but this is inconsistent with 
the previous wording in at line 9 which says "identity information for said mobile device", 
and the wording at lines 1 0-1 1 and 1 6, "mobile device identity information ". This 
amendment is relevant to patentability because the "mobile device identity information" 
referred to in the claim is defined by lines 7-9 of the claim as being the identity 
information of the mobile device from which the client device receives the first part of 
the authorization data. 

The applicant thanks the Examiner for allowing entry of the claim amendments 
made in the Response After Final filed on 3 May, as indicated in the Advisory Action of 
21 May 2010. The claims reflect the entered amendments. 

No new matter is presented in making this amendment. 
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Claim rejections - 35 USC §1 1 2 
The Examiner's prior rejection of claim 37 as indefinite is believed to be 
overcome by the amendment that was in the Response After Final. 

Claim reiections - 35 USC 5102 
The Examiner has repeated a rejection of claim 36 as anticipated under 35 USC 
102(e) by US Pat 7,239,226 to Berardi ("Berardi '226"). This rejection is mooted by 
cancellation of claim 36. 

Claim reiections - 35 USC §103 
The Examiner has made several obviousness rejections that start with Berardi 
'226 as the primary reference. Applicant respectfully traverses all of these rejections. 
Berardi '226, Adam '710, Campisano '447 and Shore '662 
The first rejection is a repetition of a rejection of claims 1-7, 9-12 and 38-43, 
which are considered obvious over Berardi '226 in view of Adam '71 0, Campisano '447 
and Shore '662. 

Although applicant in general repeats the arguments made in the 3 May 
Response After Final Rejection, applicant notes that claim 1 has been amended to refer 
consistently to "identity information" instead of "identity data," with reference to the 
mobile device. Applicant also notes that it has already objected to the "mosaic" nature 
of combining these references without articulated reasoning and asserts that this is 
supported by the KSR examination guidelines published by Commissioner Kappos and 
effective on 1 September 2010. 

The Examiner suggests that Berardi '226 teaches everything in claim 1 except for 
"at least one server device for providing data and/or processes to support a transaction 
using the at least one client device, said transaction including verification of 
authorisation data" and "wherein the at least one server device is provided with a user 
data store adapted to store one or more sets of user-specific data for use in authorising 
transactions", which are taught by Adam '710, the feature of "said at least one server 
device being adapted to store a second part of the authorisation data comprising 
financial data relating to a user of the mobile device in association with said first part of 
the authorisation data and the mobile device identity information and, in response to 



11 



Response to Office Action of: 3 IVIarch 2010 
Response Dated: 3 September 2010 
Title: Mobile Payments System 



App. No.: 10/553,360 
Inventor: Davies et al. 
Examiner: Monfeldt, Sarah M 



receiving said first part of the autliorisation data and tfie mobile device identity 
information, to verify said authorisation data and to retrieve said second part of the 
authorisation data comprising the user's financial data to complete a transaction" which 
is taught by Adam 710 in view of Campisano '447, and the feature "wherein the at least 
one server device is provided with a user data maintenance process for storing and 
updating user data in the user data store", which is taught by Shore '662. 

Applicant considers this objection to be an improper "mosaic" type argument that 
the different features of the claim can be separately found in different ones of a plurality 
of documents, in this case that different features of claim 1 can be separately found in 
four different documents. The mere identification of separate disclosures of the different 
features of the claim in different documents does not show that "the subject matter as a 
whole would have been obvious" unless it can be explained with "articulated reasoning" 
why the skilled person would be motivated in an obvious manner to select the different 
features of the claim from the different documents and then to combine them to arrive at 
the subject matter of the claim, with the combined results operating in a predictable 
manner. 

Further, applicant does not accept the Examiner's analysis of the prior art in this 
rejection as being correct. In particular, it is not accepted that the feature of "said at 
least one server device being adapted to store a second part of the authohsation data 
comprising financial data relating to a user of the mobile device in association with said 
first part of the authorisation data and the mobile device identity information and, in 
response to receiving said first part of the authorisation data and the mobile device 
identity information, to verify said authorisation data and to retrieve said second part of 
the authorisation data comprising the user's financial data to complete a transaction", is 
taught by Adam 71 0 in view of Campisano '447. 

Adam '710, and in particular the referenced paragraphs [0028], [0039], [0128], 
[0129] and [0168] thereof, teaches a server storing financial data associated with a 
customer identity. See paragraphs [0039], [0128] and [0129]. The server is arranged to 
receive from a point of service device a customer ID, a merchant ID and transaction 
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details. The server uses the customer ID, merchant ID and transaction details to verify 
and authorize the transaction. 

However, even if the customer ID of Adam 710 were to be regarded as 
corresponding to a first part of authorisation data according to claim 1 , Adam 710 still 
fails to teach a server "being adapted to store a second part of the authorisation data 
compnsing financial data relating to a user of the mobile device in association with said 
first part of the authorisation data and the mobile device identity information " and "in 
response to receiving said first part of the authorisation data and the mobile device 
identity information " proceeding to "verify said authorisation data and to retrieve said 
second part of the authorisation data comprising the user's financial data to complete a 
transaction" according to claim 1 . Adam 710 lacks any teaching of a server "being 
adapted to store a second part of the authorisation data... in association with said first 
part of the authorisation data and the mobile device identity information " or "receiving 
said first part of the authorisation data and the mobile device identity information " at all. 
In particular, the referenced paragraph [0168] of Adam 710 teaches only "a first data 
communication message 57 containing the customer's ID, the merchant's ID (also 
previously assigned to him by the administrator of the system), and the sum to be paid 
(the "transaction details"), is transmitted to the local CSC 2 (53)". 

In the system of Adam 710 the mobile device identity information, that is, the 
identity of the mobile device from which the one client device has received the first part 
of the identity information, is not sent to the server. In Adam 710 mobile device identity 
information is not included in either of the first data communication message 57 or the 
second communication message 58 which are sent to the server which verifies the 
customer identification and balance. See paragraphs [0168] and [0170]. Accordingly, in 
Adam 710 it is not possible for the server to use the mobile device identity information 
to verify authorisation data because the mobile device identity information is never 
supplied to the server. 

The examiner has identified the disclosure of Adam 71 0 in view of Gampisano 
'447 as relevant, and in particular suggests that Gampisano '447 would make it obvious 
to one of normal skill in the art to add to the teaching of Berardi '226 and Adam '71 0 the 
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features of cross-linking of a card holders phone number to the credit card number and 
providing the customer with a corresponding PIN. 

However, even if the teaching of Campisano '447 that a user home telephone 
number can be used as a user identifier and that a user can select multiple PINs each 
corresponding to different credit cards is taken into account, the Examiner does not 
indicate why this would suggest to the skilled person that the teaching of Adam 71 0 that 
a customer ID should be sent to a server should be extended to, or understood as, the 
feature of claim 1 of "receiving said first part of the authorisation data and the mobile 
device identity information ". 

Campisano '447, at column 2 lines 22 to 24, 32 to 34 and 42 to 43, teaches a 
payment system in which a user inputs their home phone number and a PIN in order to 
make a payment. See in particular Campisano '447, column 2 lines 22 and 23 "enter 
the cardmember's ten-digit home telephone number and PIN". This home telephone 
number is used to identify the user in place of a credit card number in order to allow the 
cardholder make purchases without the actual credit card without the cardholder having 
to memorize the twenty-digit credit card number. See column 1 , lines 15 to 24. 

There is no requirement in Campisano '447 that a telephone should be used to 
carry out a credit card transaction. It is clearly explained that a cardholder can provide 
their home phone number to carry out purchases at any purchase location. See column 
2, lines 1 3 to 1 6. Even when an order is placed by telephone in Campisano '447, there 
is no requirement that the home telephone number given by the cardholder is the 
number from which they are is calling. See column 2, lines 1 6 to 1 9. "Any telephone 
can be considered a point of purchase location since it is possible to telephone... and 
place a credit card order over the phone. 

Thus, the cardholder's home phone number of Campisano '447 is neither the 
same thing as, nor equivalent to, the mobile device identity information of claim 1 . The 
cardholder's home phone number of Campisano '447 is merely the number of a home 
telephone associated with the cardholder. This home telephone does not need to be 
used in the credit card transaction in any way. In contrast, the mobile device identity 
information of claim 1 is the identity of the mobile device which is actually being used to 
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carry out the transaction. Specifically, claim 1 requires that the mobile device identity 
information is the identity of the mobile device from which the at least one client device 
has received the first part of the identity authorization data and the identity information 
for the mobile device. See claim 1 "wherein the at least one client device is adapted to 
receive from a mobile device a first part of the authorisation data and identity 
information for said mobile device ". 

Accordingly, the skilled person, aware of both Adam 71 0 and Campisano '447, 
could understand that the customer ID sent to the server in Adam 710 could be, instead 
of a credit card number, the customer's home phone number, as taught in Campisano 
'447. However, there is nothing in the combined teachings which would lead the skilled 
person to consider changing the teaching of Adam '710 of a server storing financial data 
associated with a customer identity, the server being arranged to receive from a point of 
service device a customer ID (which, according to Campisano '447, could be a 
customer home phone number), a merchant ID and transaction details and to use these 
to verify and authorize the transaction, to add the features of claim 1 of the server also 
storing mobile device identity information and responding to receiving both a first part of 
authorisation data and mobile device identity information, which mobile device identity 
information is the identity of a mobile device from which the first part of the identity 
authorization data was received. 

Thus, even if Adam '710 is read in view of Campisano '447, this would not teach 
the skilled person the feature of a server "being adapted to store a second part of the 
authorisation data comprising financial data relating to a user of the mobile device in 
association with said first part of the authorisation data and the mobile device identity 
information " and "in response to receiving said first part of the authorisation data and 
the mobile device identity information " proceeding to "verify said authorisation data and 
to retrieve said second part of the authorisation data comprising the user's financial data 
to complete a transaction" according to claim 1 . 

The Examiner states that "it would have been obvious to one of ordinary skill in 
the art at the time of the invention to expand the apparatus of Berardi et al. to include 
the CSC to administer accounts of merchants and customers as taught by Adam et al. 
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and cross-linking of a card holders phone number to the credit card number and 
providing the customer with a corresponding PIN". As explained above, even if one of 
ordinary skill in the art were to do this, the combination would only allow them to use a 
card holder's home phone number as a customer identifier, as taught by Campisano 
'447. Nothing in the combined teachings would lead one of ordinary skill in the art to 
predictably replicate the features of a server storing or responding to a first part of 
authorisation data arid mobile device identity information according to claim 1 . 

Thus, contrary to the Examiner's arguments, this feature of claim 1 cannot be 
arrived at by combining the teaching of Berardi '226, Adam '710 and Campisano '447. 
Accordingly, it is respectfully submitted that claim 1 is not obvious and its proper 
dependent claims 2-7, 9-12 and 38-43 are also allowable as proper dependent claims. 

Further to the comments above regarding the number of references required to 
make some of the obviousness rejections, it is respectfully submitted that where, as in 
this case, four different references must be combined, and even then some of the claim 
features are still not taught by the combined disclosure of the references, this should be 
regarded by the examiner as evidence that the claimed subject matter is not obvious. 

Berardi '226, Adam '710, Campisano '447, Shore '662 and Nguyen '361 

The Examiner has repeated a rejection of claim 8 as obvious over the 
combination of Berardi '226, Adam '710, Campisano '447, Shore '662 and Nguyen '361. 
The Examiner again makes unsupported conclusory statements as to what would have 
been obvious at the time of the invention to one of ordinary skill, ignoring the obvious 
problems of requiring five separate patent teachings to predictably interact. Further, it is 
respectfully submitted that claim 1 is not obvious and its proper dependent claim 8 is 
also allowable as a proper dependent claim. 

Berardi '226, Adam '710, Campisano '447, Shore '662 and Grunbok, Jr '603 

The Examiner has repeated a rejection of claim 13 as obvious over the 
combination of Berardi '226, Adam '71 0, Campisano '447, Shore '662, and Grunbok, Jr 
'603. discussed above to include the feature "wherein the at least one server device is 
provided with a scanning process for scanning through the ordered list until a sufficient 
balance is found to complete the transaction." The Examiner again makes unsupported 
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conclusory statements as to what would have been obvious at the time of the invention 
to one of ordinary sl<ill, ignoring the obvious problems of requiring five separate patent 
teachings to predictably interact. Further, it is respectfully submitted that claim 1 is not 
obvious and its proper dependent claim 13 is also allowable as a proper dependent 
claim. 

Berardi '226, Adam '710, Campisano '447, Shore '662 and Sohaei '308 

The Examiner has repeated a rejection of claims 44 and 45 as obvious over the 
combination of Berardi '226, Adam 71 0, Campisano '447, Shore '662 and Sohaei '308. 
The Examiner again makes unsupported conclusory statements as to what would have 
been obvious at the time of the invention to one of ordinary skill, ignoring the obvious 
problems of requiring five separate patent teachings to predictably interact. Further, it is 
respectfully submitted that claim 1 is not obvious and its proper dependent claims 44 
and 45 are also allowable as proper dependent claims. 

Berardi '226, Adam '710 and Campisano '447 

The Examiner has repeated a rejection of claims 14, 16-23 and 25 as obvious 
over Berardi '226, in view of Adam '71 0 and Campisano '447. 

The Examiner suggests that Berardi '226 teaches the features of claim 14 with 
the exception of the features "at least one server device for providing data and/or 
processes to support a transaction using the at least one client device, said transaction 
including verification of authorisation data", which is taught by Adam '710, and the 
feature of "wherein the at least one server device is adapted to store said mobile device 
identity information and said authorisation data including a second part of the 
authorisation data comprising financial data relating to a user of the mobile device and, 
in response to receiving said first part of the authorisation data and the mobile device 
identity information, to verify said authorisation data and to retrieve said second part of 
the authorisation data comprising the user's financial data to complete a transaction" 
which is taught by Adam '710 in view of Campisano '447. 

This rejection is similar to the improper "mosaic" type argument used against 
independent claim 1 above. In this case, the Examiner asserts that the features of claim 
14 can be separately found in three different documents. Again, it is respectfully 
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submitted that the mere identification of separate disclosures of the different features of 
the claim in different documents does not show that "the subject matter as a whole 
would have been obvious" unless it can be explained why the skilled person would be 
motivated in an obvious manner to select the different features of the claim from the 
different documents and then to combine them to predictably provide an operative 
solution to the problem. 

Further, the Examiner's analysis of the prior art is not accepted by the Applicant. 
In particular, it is not accepted that the feature of "the at least one server device is 
adapted to store said mobile device identity information and said authorisation data 
including a second part of the authorisation data comprising financial data relating to a 
user of the mobile device and, in response to receiving said first part of the authorisation 
data and the mobile device identity information, to verify said authorisation data and to 
retrieve said second part of the authorisation data comprising the user's financial data to 
complete a transaction", is taught by Adam 710 in view of Campisano '447. 

Adam 710, and in particular the referenced paragraphs [0028], [0039], [0128], 
[0129] and [0168], teaches a server storing financial data associated with a customer 
identity, see paragraphs [0039], [0128] and [0129], the server being arranged to receive 
from a point of service device a customer ID, a merchant ID and transaction details, see 
paragraph [0168], and to use these to verify and authorize the transaction. 

However, even if the customer ID of Adam 710 were to be regarded as 
corresponding to a first part of authorisation data according to claim 1 , Adam 710 still 
fails to teach a server "adapted to store said mobile device identity information and said 
authorization data including a second part of the authorization data comprising financial 
data relating to a user of the mobile device" and "in response to receiving said first part 
of the authorisation data and the mobile device identity information " proceeding to 
"verify said authorisation data and to retrieve said second part of the authorisation data 
comprising the user's financial data to complete a transaction" according to claim 14. 
Adam 71 0 lacks any teaching of a server adapted to store said mobile device identity 
information and said authorization data including a second part of the authorization data 
comprising financial data relating to a user of the mobile device" or "in response to 
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receiving said first part of the autliorisation data and tlie mobile device identity 
information " proceeding to "verify said autfiorisation data and to retrieve said second 
part of the authorisation data comprising the user's financial data to complete a 
transaction" at all. In particular, the referenced paragraph [0168] of Adam 710 teaches 
only "a first data communication message 57 containing the customer's ID, the 
merchant's ID (also previously assigned to him by the administrator of the system), and 
the sum to be paid (the "transaction details"), is transmitted to the local CSC 2 (53)". 

In the system of Adam 710 the mobile device identity information, that is, the 
identity of the mobile device from which the one client device has received the first part 
of the identity information, is not sent to the server. In Adam 710 mobile device identity 
information is not included in either of the first data communication message 57 or the 
second communication message 58 which are sent to the server which verifies the 
customer identification and balance. See paragraphs [0168] and [0170]. Accordingly, in 
Adam 71 0 it is not possible for the server to use the mobile device identity information 
to verify authorisation data because the mobile device identity information is never 
supplied to the server. 

The examiner has identified the disclosure of Adam 710 in view of Campisano 
'447 as relevant, and in particular suggests that Campisano '447 would make it obvious 
to one of normal skill in the art to add to the teaching of Berardi '226 and Adam '710 the 
features of cross-linking of a card holders phone number to the credit card number and 
providing the customer with a corresponding PIN. 

However, even if the teaching of Campisano '447 that a user home telephone 
number can be used as a user identifier and that a user can select multiple PINs each 
corresponding to different credit cards is taken into account, the Examiner does not 
indicate why this would suggest to the skilled person that the teaching of Adam '71 0 that 
a customer ID should be sent to a server should be extended to, or understood as, the 
feature of claim 14 of "receiving said first part of the authorisation data and the mobile 
device identitv information ". 

Campisano '447, at column 2 lines 22 to 24, 32 to 34 and 42 to 43, teaches a 
payment system in which a user inputs their home phone number and a PIN in order to 
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make a payment. See in particular Campisano '447, column 2 lines 22 and 23 "enter 
the cardmember's ten-digit home telephone number and PIN". This home telephone 
number is used to identify the user in place of a credit card number in order to allow the 
cardholder make purchases without the actual credit card without the cardholder having 
to memorize the twenty-digit credit card number. See column 1 , lines 15 to 24. 

There is no requirement in Campisano '447 that a telephone should be used to 
carry out a credit card transaction. It is clearly explained that a cardholder can provide 
their home phone number to carry out purchases at any purchase location. See column 
2, lines 1 3 to 1 6. Even when an order is placed by telephone in Campisano '447, there 
is no requirement that the home telephone number given by the cardholder is the 
number from which they are is calling. See column 2, lines 1 6 to 19 "Any telephone can 
be considered a point of purchase location since it is possible to telephone... and place 
a credit card order over the phone. 

Thus, the cardholder's home phone number of Campisano '447 is neither the 
same thing as, nor equivalent to, the mobile device identity information of claim 14. The 
cardholder's home phone number of Campisano '447 is merely the number of a home 
telephone associated with the cardholder. This home telephone does not need to be 
used in the credit card transaction in any way. In contrast, the mobile device identity 
information of claim 14 is the identity of the mobile device which is actually being used 
to carry out the transaction. Specifically, claim 14 requires that the mobile device 
identity information is the identity of the mobile device from which the at least one client 
device has received the first part of the identity authorization data and the identity 
information for the mobile device. See claim 14 "wherein the at least one client device is 
adapted to receive from a mobile device identity information for said mobile device and 
a first part of the authorisation data". 

Accordingly, the skilled person aware of both Adam '71 0 and Campisano '447 
could understand that the customer ID sent to the server in Adam '710 could be, instead 
of a credit card number, the customer's home phone number, as taught in Campisano 
'447. However, there is nothing in the combined teachings which would lead the skilled 
person to consider changing the teaching of Adam 710 of a server storing financial data 
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associated with a customer identity, the server being arranged to receive from a point of 
service device a customer ID (which, according to Campisano '447, could be a 
customer home phone number), a merchant ID and transaction details and to use these 
to verify and authorize the transaction, to add the features of claim 14 of the server also 
storing mobile device identity information and responding to receiving both a first part of 
authorisation data and mobile device identity information, which mobile device identity 
information is the identity of a mobile device from which the first part of the identity 
authorization data was received. 

Thus, even if Adam 710 is read in view of Campisano '447, this would not teach 
the skilled person the feature of a server "adapted to store said mobile device identity 
information and said authorisation data including a second part of the authorisation data 
comprising financial data relating to a user of the mobile device and, in response to 
receiving said first part of the authorisation data and the mobile device identity 
information, to verify said authorisation data and to retrieve said second part of the 
authorisation data comprising the user's financial data to complete a transaction" 
according to claim 14. 

The Examiner states that "it would have been obvious to one of ordinary skill in 
the art at the time of the invention to expand the apparatus of Berardi et al. to include 
the CSC to administer accounts of merchants and customers as taught by Adam et al. 
and cross-linking of a card holders phone number to the credit card number and 
providing the customer with a corresponding PIN". As explained above, even if one of 
ordinary skill in the art were to do this, the combination would only allow them to use a 
card holder's home phone number as a customer identifier, as taught by Campisano 
'447. Nothing in the combined teachings would lead one of ordinary skill in the art to 
predictably replicate the features of a server storing or responding to a first part of 
authorisation data and mobile device identity information according to claim 14. 

Thus, contrary to the Examiner's arguments, this feature of claim 14 cannot be 
arrived at by combining the teaching of Berardi '226, Adam '710 and Campisano '447. 
Accordingly, it is respectfully submitted that claim 14 is not obvious and its proper 
dependent claims 16-25 are also allowable as proper dependent claims. 
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Further to the comments above regarding the number of references required to 
make some of the obviousness rejections, it is respectfully submitted that where, as in 

this case, three different references must be combined, and even then some of the 
claim features are still not taught by the combined disclosure of the references, this 
should be regarded by the examiner as evidence that the claimed subject matter is not 
obvious. 

Berardi '226, Adam '710, Campisano '447 and Grunbok '603 

The examiner has repeated a suggestion that Berardi '226 teaches the features 
of claim 26 with the exception of the features "at least one server device for providing 
data and/or processes to support a transaction using the at least one client device, said 
transaction comprising a transfer of funds between financial accounts and including 
verification of authorisation data"; "update means for updating data representing a cash 
amount"; "the at least one server device is adapted to store said identity information for 
said mobile device and said authorisation data including a second part of the 
authorisation data comprising financial data relating to a user of the mobile device and, 
in response to receiving said first part of the authorisation data and said identity 
information for said mobile device, to verify said authorisation data and to retrieve said 
second part of the authorisation data comprising the user's financial data to support a 
transaction"; and "transaction comprising a transfer of funds at least in part by updating 
the data representing a cash amount". 

Again, this objection appears to be an improper "mosaic" type argument that the 
different features of the claim can be separately found in different ones of a plurality of 
documents, in this case that different features of claim 26 can be separately found in 
four different documents. It is respectfully submitted that the mere identification of 
separate disclosures of the different features of the claim in different documents does 
not show that "the subject matter as a whole would have been obvious" unless it can be 
explained why the skilled person would be motivated in an obvious manner to select the 
different features of the claim from the different documents and then to combine them to 
arrive at the subject matter of the claim. 
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Further, the Examiner's analysis of the prior art is not accepted by the Applicant. 
In particular, applicant rejects the assertion that the feature of "the at least one server 
device is adapted to store said identity information for said mobile device and said 
authorisation data including a second part of the authorisation data comprising financial 
data relating to a user of the mobile device and, in response to receiving said first part 
of the authorisation data and said identify information for the mobile device, to verify 
said authorisation data and to retrieve said second part of the authorisation data 
comprising the user's financial data to support a transaction", is taught by Adam 71 0 in 
view of Campisano '447. 

This feature essentially corresponds to the feature of claim 14 "the at least one 
server device is adapted to store said mobile device identity information and said 
authorisation data including a second part of the authorisation data comprising financial 
data relating to a user of the mobile device and, in response to receiving said first part 
of the authorisation data and the mobile device identity information, to verify said 
authorisation data and to retrieve said second part of the authorisation data comprising 
the user's financial data to complete a transaction" which was discussed above. 

The only substantive difference between these features is that claim 14 refers to 
financial data to "complete" a transaction whereas claim 26 refers to financial data to 
"support" a transaction. Othenwise the differences are merely minor matters of 
nomenclature such as using "mobile device identity information" in place of "identity 
information for said mobile device". 

Applicant respectfully asserts that these differences in wording are not relevant to 
the arguments regarding obviousness of this feature set out above. Further, it is 
submitted that even according to the arguments in the Office Action the teaching of the 
further cited document Grunbok '603 relates only to stored data representing a cash 
amount and is not relevant to obviousness of the identified feature. 

Accordingly, it is submitted that for corresponding reasons to those set out above 
for claim 14, this feature of claim 26 cannot be arrived at by combining the teaching of 
Berardi '226, Adam '710, Campisano '447 and Grunbok '603. Accordingly, it is 
respectfully submitted that claim 26 is not obvious, that claims 27 and 28 allowable as 
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proper directly dependent claims and that dependent claims 29 and 30 are not obvious 
because they depend from an allowable proper dependent claim. 

Adam '710, Nguyen '361 and Shore '662 

The Examiner rejects claims 31-32 as obvious over Adam 710 in view of Nguyen 
'361 and Shore '662. This rejection is mooted by cancellation of the claims. 

Grunbok '603 and Nguyen '361 

The Examiner has repeated a suggestion that Grunbok '603 discloses all 
features of claim 34 except for the feature of "a data store for storing user specific data 
in association with at least one of said identifiers", and further suggests that this feature 
is disclosed by Nguyen '361 . 

First, applicant respectfully submits that the term "price list" is well known in the 
art and does not require an explicit definition of the term for one of ordinary skill to 
understand the scope of the term. 

Applicant respectfully submits that this analysis is incorrect. Applicant asserts 
that Grunbok '603 does not disclose the feature of "a price list computer program for 
processing a price list arising from a transaction... the price list processor is adapted to 
process a price list arising from a transaction by applying user specific data," as 
Grunbok '603 teaches only methods of arranging payment of a transaction. 

There is no disclosure in Grunbok '603 of processing a price list arising from a 
transaction by applying user specific data. The cited text of Grunbok '603 at column 6, 
lines 20-31 , and column 5, lines 10-33, teaches only how the cost of a purchase can be 
met by taking funds from a plurality of different user accounts. There is no teaching 
whatsoever that a price list of a transaction can be processed in any way, and certainly 
no teaching that the price list arising from a transaction can be processed by applying 
user specific data according to the feature of claim 34. 

It is submitted that even if arranging payment of a purchase according to 
Grunbock '603 was to be regarded as teaching "process a price list" it cannot 
reasonably be regarded as teaching "process a price list... by applying user specific 
data" according to claim 34. 
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An example of processing of a price list of a transaction by applying user specific 
data is for a loyalty scheme in which a user may have a discount arising from their 
purchasing history, as explained at page 5, line 31 , to page 6, line 2, of the application 
as originally filed. However, it is stressed that this is merely an example and that 
Grunbok '603 does not teach or suggest that a price list of a transaction can be 
processed in any way by applying user specific data. 

This feature is also not taught by Nguyen '361 . Although Nguyen '361 teaches a 
data store there is nothing in the specification to teach or suggest in any way that the 
price list arising from a transaction can be processed by applying user specific data. 

Accordingly, applicant asserts that claim 34 is allowable over this combination of 
references, and that claim 35 is also allowable as a proper dependent claim. 

Adam '710 and Nguyen '361 

Instead of repeating a rejection of claim 37 as obvious over Berardi '226, Adam 

'71 0 and Nguyen '361 , the Examiner rejects claim 37 as obvious over just Adam '71 0 
and Nguyen '361 . The Examiner accepts that the features of claim 37 of a 
communication device "having an address in a public network" and of "transmitting the 
generated receipt to a communication device having a different address in a public 
network" is not taught by Adam '710, but the Examiner suggests that these features are 
taught by Nguyen '361, particularly at paragraphs [0006] and [0018]. 

In the Advisory Action, the Examiner indicates that the arguments presented in 
the Response After Final are "moot in view of the new grounds of rejection." 
Respectfully, applicant sees no new grounds of ejection set forth with regard to claim 37 
in the Advisory Action, so it at a loss as to how to respond. 

Accordingly, it is respectfully submitted that claim 37 is allowable over this 
combination of references. 

Respectfully submitted, 

Date: 3 September 2010 By: /Stephen L. Grant. Reg No 33.390/ 

Stephen L. Grant 
Attorney for Applicants 
Registration No. 33,390 
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